IBIS Macromodel Task Group

Meeting date: 26 September 2017

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                              Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Walter to modify his BIRD158.6 draft 7 according to the meeting discussions
  and send it to Bob R., Mike L., Arpad, and Radek for final review.
  - Done.

- Bob Ross, et. al., to perform final review and editing and post it as
  BIRD158.6 draft 8.
  - Done.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

BIRD158.6:
- Arpad: I hope we can complete a final review and vote to submit this to the
         Open Forum.
  - [sharing draft8 and his email with a few comments/suggestions]
- Discussion: Arpad noted some concern about the location of the text
  explaining that the triangle ground symbols are connected.  He felt that its
  current location under the Tx figure might leave readers thinking it only
  applied to the Tx.  He and Bob noted that Radek had suggested the text could
  be placed after the entire-channel figure, or after all three figures.  Bob
  and Arpad wondered about the use of the term "Node 0" and if that might be
  better explained.  Arpad, Bob R., Radek, and Mike L., contributed thoughts on
  the text, and the group arrived at:
     The triangle ground symbols in the Tx, Rx, and channel circuits represent
     the same node.  This node would typically be the global ground, such as
     node 0 in IBIS-ISS.
  Arpad placed this text under each of the 3 figures (Tx, Rx, Channel).  Bob
  noted that at a later date we may want to consolidate into one statement
  in a single location (instead of 3 copies) as an editorial matter.  
  
  Arpad noted that he had also wanted to add an explanation of the default
  value of the optional Rx_R in the paragraph below the Rx figure.  He and Radek
  proposed adding "(default is open circuit)".  The group agreed.
  
  Arpad noted that he preferred to change "input to the Rx algorithmic model"
  to "input of the Rx algorithmic model."  No one objected.
  
- Arpad: I will save this as draft 9.
- Bob: I move to submit this draft9 to the IBIS Open Forum as BIRD158.6.
- Walter: Second.  [no one opposed]
- Arpad: I will send an email to the Open Forum introducing BIRD158.6.

IBIS 7.0:
- Walter: Now that we have BIRD158, is there anything major left for IBIS 7.0
          other than BIRD189?
- Michael M.: I don't think so.
  - My understanding is that the C_comp improvements are not for 7.0?
- Walter: That's correct.
- Michael M.: In that case, yes, I believe BIRD189 is the last major technical
              BIRD for IBIS 7.0.
              
BIRD 189:
- Walter: I propose we use the rest of this meeting for BIRD 189.
- Arpad: I've become concerned about the [Interconnect Model Set] keyword.  We
         can have multiple [Interconnect Model]s inside of it, but we don't have
         any rules to restrict the way those Models should be written.  Someone
         might provide models that represent multiple options for the same set
         of pins.  Someone else might provide models that provide different
         portions of the path for given pins (for example buffer to pad in one
         model and pad to pin in another).  In the former situation you might
         require a selector from the EDA tool so the user can choose a model
         from the set.  In the latter situation you wouldn't, because all of
         the models in the set have to be used.
  - When the new [Interconnect Model Set Group] keyword was introduced, I was
    under the impression that this would be the only thing that would require
    a selection from the user in case the model maker created multiple groups.
    But now it occurs to me that inside the [Interconnect Model Set] itself we
    may still have an ambiguity and may require user selections.
  - I wonder if we should establish some rules to eliminate the need for
    selection of Models within a Model Set.
- Bob: Yes, I agree.  I think we need a rule that no pin name is repeated
       within an [Interconnect Model Set].  That eliminates the need for
       any selection of which [Interconnect Model] to use within a Set.
       I mean that you can't have the same pin repeated at the same
       interface.  (one model could take a particular pin from buffer to pad,
       and another could take it from pad to pin interface).
- Walter: That won't work.  If you have crosstalk, you may have a situation
          where in one Model a particular net is a victim, and in another
          Model it appears as an aggressor.
  - Say I have DQ1 through DQ6.
  - One model may have DQ1, DQ2, and DQ3, where DQ2 is the victim.
  - Another model may have DQ2, DQ3, DQ4, where DQ3 is the victim.
  - Maybe you want to give a warning if two Models in the same Set have the
    same pin as a victim.  But that would just be an informative warning.
- Bob: To keep it simple put them in two different Sets.
- Walter: No, I might have a 64 DQ bus.  The model maker might typically extract
          one swath, say DQ1, DQ2, DQ3, DQ4, DQ5 with DQ3 as the victim.  They
          may then repeat instances of that same s10p for different pins.
- Mike L.: What Walter's describing is way of swathing.
  - Perhaps we could have a rule that no two Models in a Model Set would have
    exactly the same set of pins?
- Arpad: That's the type of rule I'm leaning toward.
  - If we look at example 4 in the bird189.5_draft9_v1.docx:
    - There are three different Models for the same pins, but each one is in
      a separate Model Set.
    - If we made a rule like this, that would solve this issue.
  - If we allow these types of repetitions in a Model Set, the user will have to
    make a choice.
  - It sounds like Bob and I would like to only have a selector to select from
    among the Interconnect Model Set Groups.
- Walter: I agree with that.
- Arpad: If you allow the same pin to appear multiple times as an aggressor in
         a Model Set, isn't a selection by the user required?
- Walter: No, the user knows what victim net they want to simulate.
- Bob: There is no requirement that we only simulate victim nets.
  - You can arbitrarily pick out one pin and simulate that path.
  - Or you can pick one pin as the agressor and see its effect on all the
    other pins as victims.
- Arpad: I have to think about Walter's crosstalk example more.
  - I think we have made good progress, and we agree on a preference for one
    user selection to choose the Group.

- Mike L.: Motion to adjourn.
- Curtis: Second. 
- Arpad: Thank you all for joining.

AR: Arpad to send BIRD158.6 draft 9 to Mike L. for posting as BIRD158.6.
AR: Arpad to send an email to the Open Forum introducing BIRD158.6.
AR: Mike L. to post BIRD158.6

-------------
Next meeting: 03 October 2017 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
